User-Centred Requirements Handbook |
Task analysis can be defined as the study of what a user is required to do in terms of actions and/or cognitive processes to achieve a task. A detailed task analysis can be conducted to understand the current system and the information flows within it. These information flows are important to the maintenance of the existing system and must be incorporated or substituted in any new system. Failure to allocate sufficient resources to this activity increases the potential for costly problems arising in later phases of development. Task analysis makes it possible to design and allocate tasks appropriately within the new system. The functions to be included within the system and the user interface can then be accurately specified.
Typical Application Areas
Suitable and recommended for most situations.
Benefits
Provides knowledge of the tasks that the user wishes to perform. Thus it is a reference against which the value of the system functions and features can be tested.
Limitations
Formal task analysis can be time consuming and produce much data requiring considerable effort to analyse.
What you need
It is important to gain access to real users to discuss their current or possible future tasks as well as user representatives.
Process
The process in this section is divided into two phases:
1. High level task decomposition, where major tasks are broken down into sub-tasks. This step provides a good overview of the tasks being analysed.
2. Task flow diagramming, where specific tasks are divided into the basic task steps.
Both of these phases are described in the following sections.
Practical guidelines
• Produce a 'map' of relevant users and try to understand initially their main tasks or roles.
• Identify individual people who will be able to provide correct information about the tasks that are performed. Timetable meetings to make sure that all these users can be included in the analysis.
• If necessary plan observation sessions to get a richer picture of the tasks or task problems.
• Gather as much information as possible and then try to structure it soon afterwards while it is still fresh in the memory.
• During the structuring process go back to any users to clarify your understanding.
• Try to supplement textual descriptions of tasks with diagrams such as task decompositions or task flow diagrams.
Task decomposition
The aim of 'high level task decomposition' is to decompose the high level tasks and break them down into their constituent subtasks and operations. This will show an overall structure of the main user tasks. At a lower level it may be desirable to show the task flows, decision processes and even screen layouts (see task flow analysis, below)
The process of task decomposition is best represented as a structure chart (similar to that used in Hierarchical Task Analysis). This shows the sequencing of activities by ordering them from left to right. In order to break down a task, the question should be asked 'how is this task done?'. If a sub-task is identified at a lower level, it is possible to build up the structure by asking 'why is this done?'. This approach can be summarised as shown below.
Figure 12. Process of Task Decomposition
The task decomposition can be carried out using the following stages:
1. Identify the task to be analysed from the Task list (section 1.4).
2. Break this down into between 4 and 8 subtasks. These subtasks should be specified in terms of objectives and, between them, should cover the whole area of interest.
3. Draw the subtasks as a layered diagram ensuring that it is complete.
4. Decide upon the level of detail into which to decompose. Making a conscious decision at this stage will ensure that all the subtask decompositions are treated consistently. It may be decided that the decomposition should continue until flows are more easily represented as a task flow diagram.
5. Continue the decomposition process, ensuring that the decompositions and numbering are consistent. It is usually helpful to produce a written account as well as the decomposition diagram.
6. Present the analysis to someone else who has not been involved in the decomposition but who knows the tasks well enough to check for consistency.
The following structure chart represents a hierarchical decomposition of a function into its components. It shows the sequencing of activities by ordering them from left to right. Activities that may be repeated a number of times (iteration) are indicated by a small asterisk in the box. When one of a number of activities may be chosen (selection) a small circle is included in the box. A horizontal line in a box can be used to indicate no action, for example where the user can choose to take an action or not. Where appropriate a sub-task or group of sub-tasks can be represented as a flow diagram. The circles labelled 'TF1' and 'TF2' show the links to task flow diagrams.
Figure 13. Task decomposition diagram
As previously stated, it is important that the requirements definition process does not simply record existing operations but also assesses the likely changes resulting from the introduction of new systems and facilities. The implications of likely changes should be recorded on the task decomposition diagrams themselves. This can be done by the use of comments at the bottom of the diagram with reference to the task decomposition box numbers (e.g. 2.1.1 or 2.1.2).
Task flow diagrams
Task flow analysis will document the details of specific tasks. It can include details of interactions between the user and the current system, or other individuals, and any problems related to them. Copies of screens from the current system may also be taken to provide details of interactive tasks. Task flows will not only show the specific details of current work processes but may also highlight areas where task processes are poorly understood, are carried out differently by different staff, or are inconsistent with the higher level task structure.
An example task flow chart is shown below. Standard flow chart symbols may be used to represent process, decision points, system inputs, output, etc. However the actual notation used is not important and an alternative set of symbols may be used if preferred.
Figure 14. Task flow chart
Further information
Preece (1994), Shepherd (1985, 1989).